fix(accounts): say what a failed personal principal actually needs - #31

Summary

Creating a personal principal against an older auth plane fails with a raw Postgres message naming a column the client never sent:

null value in column "allowed_mask" of relation "principals" violates not-null constraint

The cause is server-side and worth recording. On that schema vintage principals still carries the mask itself (allowed_mask bit(bitlen), NOT NULL), and the generated create_principal sizes it by looking the width up at runtime:

SELECT bit_length(permissions) FROM <general sprt> LIMIT 1 INTO v_perm_bitlen;
IF allowed_mask IS NULL THEN v_allowed_mask := repeat('1', v_perm_bitlen)::varbit; …

With no visible permission row the lookup yields NULL, repeat('1', NULL) is NULL, and the insert trips the constraint — so the failure surfaces as a NOT NULL violation rather than as "you have no permission row". create_org_principal reads the org SPRT, which does have rows, which is why only the personal path breaks. Later schemas moved the mask to principal_scope_overrides, where an absent row means "inherits", and drop the column entirely.

Nothing client-side can supply the width, so this only translates the error into the two things that do work — scope it to an organization, or update the auth plane — through the existing explainFailure (renamed from the module-private explain so it can be tested), which every rethrow already passes through.

Testing

explainFailure rewrites the mask constraint and leaves an unrelated failure (permission denied for table principals) byte-identical. Accounts build, lint and 48 tests green.

Link to Devin session: https://app.devin.ai/sessions/04636534e07048089ffb6b78142e12cd
Requested by: @pyramation